Use PartialType from @nestjs/mapped-types to create an UpdateDto where all fields are optional but retain their original validation decorators. Combine with skipMissingProperties: true in ValidationPipe so absent fields are not validated at all. This ensures PATCH only updates provided fields while still validating the ones that are sent.

PartialType for PATCH endpoint DTOs

PATCH endpoint best practices:

1
PartialType wraps every field with @IsOptional() while preserving all other decorators.
2
Also available from @nestjs/swagger — use that version to keep Swagger documentation accurate.
3
skipMissingProperties: true in ValidationPipe skips validation for fields not sent in the request.
4
PATCH should apply partial updates — only modify fields that are present in the request body.
5
PUT should replace the entire resource — all required fields must be present in the body.

Difficulty: 6/10

Topics: PartialType, DTO validation, PATCH endpoint

Scenario Questions

0-2 years experience

1
How would you implement a PATCH /users/:id endpoint that reuses the CreateUserDto with PartialType?
2
What happens if a client omits a field that is required in the original DTO when you use PartialType?
3
Can you sketch the DTO class and controller method code for this partial update?

2-5 years experience

1
We added PartialType to our OrderUpdateDto but some fields are still being validated as required. Walk me through how you'd debug the issue.
2
Explain the trade‑offs between using PartialType versus manually marking each property optional in a large DTO.
3
If a client sends an empty JSON body to the PATCH endpoint, how would you ensure the request is rejected appropriately?

5-8 years experience

1
When supporting partial updates for many resources, how would you design a reusable pattern with PartialType that minimizes performance impact?
2
Describe how you would handle nested objects—like updating an address inside a UserDto—using PartialType and class‑validator.
3
What considerations do you make for API versioning when the underlying DTO shape changes but old PATCH contracts must remain functional?

8+ years experience

1
Our ecosystem has dozens of NestJS microservices. How would you architect a shared library for PartialType‑based DTOs, validation pipelines, and error handling while keeping services decoupled?
2
If we decide to migrate from class‑validator to a custom validation framework, how would you refactor existing PartialType DTOs to reduce risk?
3
Describe a long‑term maintenance strategy to keep partial update endpoints backward compatible as the data model evolves across teams.

Follow-up Questions

❓How does NestJS's ValidationPipe treat optional properties generated by PartialType?
❓If you needed to aggregate multiple validation errors into a single response, what would you change?
❓What unit or e2e tests would you write to verify the PATCH behavior?